Entity Classes

`connection`

A transfer of commodities between nodes. E.g. electricity line, gas pipeline...

Related Entity Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__investment_group, connection__investment_stochastic_structure, connection__investment_temporal_block, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node, connection__user_constraint and stage__output__connection

Related Parameters: availability_factor, benders_starting_connections_invested, binary_gas_flow_active, connection_investment_cost, connection_min_factor, connection_type, contingency_active, decommissioning_cost, decommissioning_time, discount_rate_technology_specific, existing_connections, fixed_annual_cost, investment_count_fix_cumulative, investment_count_fix_new, investment_count_initial_cumulative, investment_count_initial_new, investment_count_max_cumulative, investment_variable_type, lead_time, lifetime_constraint_sense, lifetime_economic, lifetime_technical, mga_investment_active, mga_investment_big_m, mga_investment_weight, monitoring_active, reactance_base, reactance and resistance

A connection represents a transfer of one commodity over space. For example, an electricity transmission line, a gas pipe, a river branch, can be modelled using a connection.

A connection always takes commodities from one or more nodes, and releases them to one or more (possibly the same) nodes. The former are specified through the connection__from_node relationship, and the latter through connection__to_node. Every connection inherits the temporal and stochastic structures from the associated nodes. The model will generate connection_flow variables for every combination of connection, node, direction (from node or to node), time slice, and stochastic_scenario, according to the above relationships.

The operation of the connection is specified through a number of parameter values. For example, the capacity of the connection, as the maximum amount of energy that can enter or leave it, is given by capacity_per_connection. The conversion ratio of input to output can be specified using any of fix_ratio_out_in_connection_flow, max_ratio_out_in_connection_flow, and min_ratio_out_in_connection_flow parameters in the connection__node__node relationship. The delay on a connection, as the time it takes for the energy to go from one end to the other, is given by connection_flow_delay.

`connection__from_node`

A flow on a connection from a node.

Related Entity Classes: connection and node

Related Parameters: binary_gas_flow_limits_fix, binary_gas_flow_limits_initial, capacity_per_connection, capacity_to_flow_conversion_factor, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, flow_limits_fix_intact, flow_limits_fix, flow_limits_initial_intact and flow_limits_initial

connection__from_node is a two-dimensional relationship between a connection and a node and implies a connection_flow to the connection from the node. Specifying such a relationship will give rise to a connection_flow variable with indices connection=connection, node=node, direction=:from_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, capacity_per_connection will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

`connection__from_node__investment_group`

A flow on a connection from a node whose capacity should be counted in the capacity invested available of an investment_group.

Related Entity Classes: connection, investment_group and node

Defining this relation between a connection__from_node and an investment_group makes it eligible to appear in the group investment constraints. However, the constraint generation is controlled by the investment_capacity_total_min_cumulative and investment_capacity_total_max_cumulative parameters.

`connection__from_node__user_constraint`

A flow on a connection from a node constrained by a user_constraint.

Related Entity Classes: connection, node and user_constraint

Related Parameters: coefficient_for_connection_flow

connection__from_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable to the specified connection from the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter coefficient_for_connection_flow defined on connection__from_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint.

`connection__investment_group`

A connection that belongs in an investment_group.

Related Entity Classes: connection and investment_group

Assigns connections to investment_groups, affecting the use of parameters like investment_capacity_total_max_cumulative or investment_capacity_total_min_cumulative.

`connection__investment_stochastic_structure`

The stochastic_structure of a connection investment.

Related Entity Classes: connection and stochastic_structure

The connection__investment_stochastic_structure relationship defines the stochastic_structure of connection-related investment decisions. Essentially, it sets the stochastic_structure used by the connections_invested_available variable of the connection.

The connection__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

`connection__investment_temporal_block`

The temporal_block of a connection investment.

Related Entity Classes: connection and temporal_block

connection__investment_temporal_block is a two-dimensional relationship between a connection and a temporal_block. This relationship defines the temporal resolution and scope of a connection's investment decision. If a model__default_investment_temporal_block is specified and no connection__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely, if connection__investment_temporal_block is specified, this will override model__default_investment_temporal_block for the specified connection.

See also Investment Optimization

`connectionnodenode`

A connection acting over two nodes.

Related Entity Classes: connection and node

Related Parameters: compression_factor, connection_flow_delay, connection_linepack_constant, fix_ratio_out_in_connection_flow, fixed_pressure_constant_0, fixed_pressure_constant_1, max_ratio_out_in_connection_flow and min_ratio_out_in_connection_flow

connection__node__node is a three-dimensional relationship between a connection, a node (node 1) and another node (node 2). connection__node__node infers a conversion and a direction with respect to that conversion. Node 1 is assumed to be the input node and node 2 is assumed to be the output node. For example, the fix_ratio_out_in_connection_flow parameter defined on connection__node__node relates the output connection_flow to node 2 to the input connection_flow from node 1

`connection__to_node`

A flow on a connection to a node .

Related Entity Classes: connection and node

Related Parameters: binary_gas_flow_limits_fix, binary_gas_flow_limits_initial, capacity_per_connection, capacity_to_flow_conversion_factor, connection_emergency_capacity, connection_flow_cost, connection_flow_non_anticipativity_margin, connection_flow_non_anticipativity_time, connection_intact_flow_non_anticipativity_margin, connection_intact_flow_non_anticipativity_time, flow_limits_fix_intact, flow_limits_fix, flow_limits_initial_intact and flow_limits_initial

connection__to_node is a two-dimensional relationship between a connection and a node and implies a connection_flow from the connection to the node. Specifying such a relationship will give rise to a connection_flow variable with indices connection=connection, node=node, direction=:to_node. Relationships defined on this relationship will generally apply to this specific flow variable. For example, capacity_per_connection will apply only to this specific flow variable, unless the connection parameter connection_type is specified.

`connection__to_node__investment_group`

A flow on a connection to a node whose capacity should be counted in the capacity invested available of an investment_group.

Related Entity Classes: connection, investment_group and node

Defining this relation between a connection__to_node and an investment_group makes it eligible to appear in the group investment constraints. However, the constraint generation is controlled by the investment_capacity_total_min_cumulative and investment_capacity_total_max_cumulative parameters.

`connection__to_node__user_constraint`

A flow on a connection to a node constrained by a `user_constraint

Related Entity Classes: connection, node and user_constraint

Related Parameters: coefficient_for_connection_flow

connection__to_node__user_constraint is a three-dimensional relationship between a connection, a node and a user_constraint. The relationship specifies that the connection_flow variable from the specified connection to the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific connection_flow variable. For example the parameter coefficient_for_connection_flow defined on connection__to_node__user_constraint represents the coefficient on the specific connection_flow variable in the specified user_constraint.

`connection__user_constraint`

A connection investment constrained by a user_constraint.

Related Entity Classes: connection and user_constraint

Related Parameters: coefficient_for_connections_invested_available and coefficient_for_connections_invested

connection__user_constraint is a two-dimensional relationship between a connection and a user_constraint. The relationship specifies that a variable or variable(s) associated only with the connection (not a connection_flow for example) are involved in the constraint. For example, the coefficient_for_connections_invested defined on connection__user_constraint specifies the coefficient of the connections_invested variable in the specified user_constraint.

`grid`

A good or product that can be consumed, produced, traded. E.g., electricity, oil, gas, water...

Related Entity Classes: node__grid

Related Parameters: lodf_tolerance, mp_min_res_gen_to_demand_ratio_slack_penalty, mp_min_res_gen_to_demand_ratio, physics_duration, physics_type and ptdf_threshold

Grids are for trading different types of commodities. When associated with a node through the node__grid relationship, a specific location can be associated with a specific grid (or form of commodity). For the representation of specific grid physics, related to e.g. the representation of the electric network, designated parameters can be defined to enforce grid specific behaviour. (See also physics_type)

`investment_group`

A group of investments that need to be done together.

Related Entity Classes: connection__from_node__investment_group, connection__investment_group, connection__to_node__investment_group, node__investment_group, unit__investment_group and unit_flow__investment_group

Related Parameters: equal_investments_active, investment_capacity_total_max_cumulative, investment_capacity_total_min_cumulative, investment_count_total_max_cumulative and investment_count_total_min_cumulative

The investment_group class represents a group of investments that need to be done together. For example, a storage investment on a node might only make sense if done together with a unit or a connection investment.

To use this functionality, you must first create an investment_group and then specify any number of unit__investment_group, node__investment_group, and/or connection__investment_group relationships between your investment_group and the unit, node, and/or connection investments that you want to be done together. This will ensure that the investment variables of all the entities in the investment_group have the same value.

`model`

An instance of SpineOpt, that specifies general parameters such as the temporal horizon.

Related Entity Classes: model__default_investment_stochastic_structure, model__default_investment_temporal_block, model__default_stochastic_structure, model__default_temporal_block and model__report

Related Parameters: benders_iterations_reporting_active, big_m, connection_flow_highest_resolution_active, connection_investment_power_flow_impact_active, decomposition_max_gap, decomposition_max_iterations, decomposition_min_iterations, discount_rate, discount_year, duration_unit, mga_max_iterations, mga_max_slack, model_algorithm, model_end, model_start, model_type, monte_carlo_scenarios, multiyear_economic_discounting, roll_forward, shared_values, solver_lp_options, solver_lp, solver_mip_options, solver_mip, tight_compact_formulations_active, window_duration, window_weight, write_lodf_file, write_mps_file and write_ptdf_file

The model object holds general information about the optimization problem at hand. Firstly, the modelling horizon is specified on the model object, i.e. the scope of the optimization model, and if applicable the duration of the rolling window (see also model_start, model_end and roll_forward). Secondly, the model works as an overarching assembler - only through linking temporal_blocks and stochastic_structures to a model object via relationships, they become part of the optimization problem, and respectively linked nodes, connections and units. If desired the user can also specify defaults for temporals and stochastic via the designated default relationships (see e.g., model__default_temporal_block). In this case, the default temporal is populated for missing node__temporal_block relationships. Lastly, the model object contains information about the algorithm used for solving the problem (see model_type).

`model__default_investment_stochastic_structure`

The default stochastic_structure of all investments in the model.

Related Entity Classes: model and stochastic_structure

`model__default_investment_temporal_block`

The default temporal_block of all investments in the model.

Related Entity Classes: model and temporal_block

model__default_investment_temporal_block is a two-dimensional relationship between a model and a temporal_block. This relationship defines the default temporal resolution and scope for all investment decisions in the model (units, connections and storages). Specifying model__default_investment_temporal_block for a model avoids the need to specify individual node__investment_temporal_block, unit__investment_temporal_block and connection__investment_temporal_block relationships. Conversely, if any of these individual relationships are defined (e.g. connection__investment_temporal_block), they will override model__default_investment_temporal_block.

See also Investment Optimization

`model__default_stochastic_structure`

The default stochastic_structure of the `model.

Related Entity Classes: model and stochastic_structure

The model__default_stochastic_structure relationship can be used to set a model-wide default for the node__stochastic_structure and units_on__stochastic_structure relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__stochastic_structure or units_on__stochastic_structure relationships take priority over the model__default_stochastic_structure relationship.

`model__default_temporal_block`

The default temporal_block of the model.

Related Entity Classes: model and temporal_block

The model__default_temporal_block relationship can be used to set a model-wide default for the node__temporal_block and units_on__temporal_block relationships. Its main purpose is to allow users to avoid defining each relationship individually, and instead allow them to focus on defining only the exceptions. As such, any specific node__temporal_block or units_on__temporal_block relationships take priority over the model__default_temporal_block relationship.

`model__report`

A report that should be written for the model.

Related Entity Classes: model and report

The model__report relationship tells which reports are written by which model, where the contents of the reports are defined separately using the report__output relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

`node`

A universal aggregator of commodify flows over units and connections, with storage capabilities.

Related Entity Classes: connection__from_node__investment_group, connection__from_node__user_constraint, connection__from_node, connection__node__node, connection__to_node__investment_group, connection__to_node__user_constraint, connection__to_node, node__grid, node__investment_group, node__investment_stochastic_structure, node__investment_temporal_block, node__node, node__stochastic_structure, node__temporal_block, node__to_unit, node__user_constraint, stage__output__node and unit__to_node

Related Parameters: balance_penalty, balance_sense, balance_type, benders_starting_storages_invested, capacity_margin_min, capacity_margin_penalty, demand_fraction, demand, existing_storages, is_non_spinning, mga_storage_investment_active, mga_storage_investment_big_m, mga_storage_investment_weight, minimum_reserve_activation_time, node_opf_type, pressure_fix, pressure_initial, pressure_max, pressure_min, reserve_active, reserve_downward, reserve_upward, storage_active, storage_decommissioning_cost, storage_decommissioning_time, storage_discount_rate_technology_specific, storage_fixed_annual_cost, storage_investment_cost, storage_investment_count_fix_cumulative, storage_investment_count_fix_new, storage_investment_count_initial_cumulative, storage_investment_count_initial_new, storage_investment_count_max_cumulative, storage_investment_variable_type, storage_lead_time, storage_lifetime_constraint_sense, storage_lifetime_economic, storage_lifetime_technical, storage_longterm_active, storage_self_discharge, storage_state_coefficient, storage_state_fix, storage_state_initial, storage_state_max_fraction, storage_state_max, storage_state_min_fraction, storage_state_min, tax_in_unit_flow, tax_net_unit_flow, tax_out_unit_flow, voltage_angle_fix, voltage_angle_initial, voltage_angle_max and voltage_angle_min

The node is perhaps the most important class out of the Systemic object classes, as it is what connects the rest together via the Systemic relationship classes. Essentially, nodes act as points in the modelled grid where commodity balance is enforced via the node balance and node injection constraints, tying together the inputs and outputs from units and connections, as well as any external demand. Furthermore, nodes play a crucial role for defining the temporal and stochastic structures of the model via the node__temporal_block and node__stochastic_structure relationships. For more details about the Temporal Framework and the Stochastic Framework, please refer to the dedicated sections.

Since nodes act as the points where commodity balance is enforced, this also makes them a natural fit for implementing storage. The storage_active parameter controls whether a node has a node_state variable, which essentially represents the commodity content of the node. The storage_state_coefficient parameter tells how the node_state variable relates to all the commodity flows. Storage losses are handled via the storage_self_discharge parameter, and potential diffusion of commodity content to other nodes via the diffusion_coefficient parameter for the node__node relationship.

`node__grid`

The grid the node is connected to. Only a single grid is permitted per node.

Related Entity Classes: grid and node

node__grid is a two-dimensional relationship between a node and a grid and specifies the grid that the node belongs to or the type of commodity that flows to or from the node. Generally, since flows are not dimensioned by grid, this has no meaning in terms of the variables and constraint equations. However, there are two specific uses for this relationship:

To specify that specific network physics should apply to the network formed by the member nodes for that grid. See powerflow
Only connection flows that are between nodes of the same or no grid are included in the node_balance constraint.

`node__investment_group`

A node that belongs in an investment_group.

Related Entity Classes: investment_group and node

Used to assign nodes to investment_groups, e.g. for constraining storages_invested_available through investment_capacity_total_min_cumulative.

`node__investment_stochastic_structure`

The stochastic_structure of a node storage investment.

Related Entity Classes: node and stochastic_structure

The node__investment_stochastic_structure relationship defines the stochastic_structure of node-related investment decisions. Essentially, it sets the stochastic_structure used by the storages_invested_available variable of the node.

The node__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

`node__investment_temporal_block`

The temporal_block of a node storage investment.

Related Entity Classes: node and temporal_block

node__investment_temporal_block is a two-dimensional relationship between a node and a temporal_block. This relationship defines the temporal resolution and scope of a node's investment decisions (currently only storage investments). If a model__default_investment_temporal_block is specified and no node__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely, if node__investment_temporal_block is specified, this will override model__default_investment_temporal_block for the specified node.

See also Investment Optimization

`node__node`

An interaction between two nodes.

Related Entity Classes: node

Related Parameters: diffusion_coefficient

The node__node relationship is used for defining direct interactions between two nodes, like diffusion of commodity content. Note that the node__node relationship is assumed to be one-directional, meaning that

node__node(node1=n1, node2=n2) != node__node(node1=n2, node2=n1).

Thus, when one wants to define symmetric relationships between two nodes, one needs to define both directions as separate relationships.

`node__stochastic_structure`

The stochastic_structure of a node. Only one stochastic_structure is permitted per node.

Related Entity Classes: node and stochastic_structure

The node__stochastic_structure relationship defines which stochastic_structure the node uses. Essentially, it sets the stochastic_structure of all the unit_flow and connection_flow variables connected to the node, as well as the potential node_state variable. Note that only one stochastic_structure can be defined per node per model, as interpreted based on the node__stochastic_structure relationship. Investment variables use dedicated relationships, as detailed in the Investment Optimization section.

The node__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

`node__temporal_block`

The temporal_block of a node and the corresponding flow variables.

Related Entity Classes: node and temporal_block

Related Parameters: cyclic_condition_sense and cyclic_condition

This relationship links a node to a temporal_block and as such it will determine which temporal block governs the temporal horizon and resolution of the variables associated with this node. Specifically, the resolution of the temporal block will directly imply the duration of the time slices for which both the flow variables and their associated constraints are created.

For a more detailed description of how the temporal structure in SpineOpt can be created, see Temporal Framework.

`node__to_unit`

A flow on a unit from a node.

Related Entity Classes: node and unit

Related Parameters: capacity_per_unit, capacity_to_flow_conversion_factor, fix_nonspin_units_started_up, flow_limits_fix_op, flow_limits_fix, flow_limits_initial_op, flow_limits_initial, flow_limits_max_cumulative, flow_limits_min_cumulative, flow_limits_min, fuel_cost, initial_nonspin_units_started_up, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_limits_down, ramp_limits_shutdown, ramp_limits_startup, ramp_limits_up, reserve_procurement_cost, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

The unit__to_node and node__to_unit unit relationships are core elements of SpineOpt. For each unit__to_node or node__to_unit, a unit_flow variable is automatically added to the model, i.e. a commodity flow of a unit to or from a specific node, respectively.

Various parameters can be defined on the node__to_unit relationship, in order to constrain the associated unit flows. In most cases a capacity_per_unit will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping.

To associate costs with a certain commodity flows, cost terms, such as fuel_costs and vom_costs, can be included for the node__to_unit relationship.

It is important to note, that the parameters associated with the node__to_unit can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the capacity_per_unit on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

`node__user_constraint`

A node state constrained by a user_constraint, or a node demand included in a user_constraint.

Related Entity Classes: node and user_constraint

Related Parameters: coefficient_for_demand, coefficient_for_node_state, coefficient_for_storages_invested_available and coefficient_for_storages_invested

node__user_constraint is a two-dimensional relationship between a node and a user_constraint. The relationship specifies that a variable associated only with the node (currently only the node_state) is involved in the constraint. For example, the coefficient_for_node_state defined on node__user_constraint specifies the coefficient of the node's node_state variable in the specified user_constraint.

`output`

A variable name from SpineOpt whose value can be included in a report.

Related Entity Classes: report__output, stage__output__connection, stage__output__node, stage__output__unit and stage__output

Related Parameters: output_resolution and output_type

An output is essentially a handle for a SpineOpt variable and Objective function to be included in a report and written into an output database. Typically, e.g. the unit_flow variables are desired as output from most models, so creating an output object called unit_flow allows one to designate it as something to be written in the desired report. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

`parent_stochastic_scenario__child_stochastic_scenario`

A parent-child relationship between two stochastic_scenarios defining the master stochastic direct acyclic graph.

Related Entity Classes: stochastic_scenario

The parent_stochastic_scenario__child_stochastic_scenario relationship defines how the individual stochastic_scenarios are related to each other, forming what is referred to as the stochastic direct acyclic graph (DAG) in the Stochastic Framework section. It acts as a sort of basis for the stochastic_structures, but doesn't contain any Parameters necessary for describing how it relates to the Temporal Framework or the Objective function.

The parent_stochastic_scenario__child_stochastic_scenario relationship and the stochastic DAG it forms are crucial for Constraint generation with stochastic path indexing. Every finite stochastic DAG has a limited number of unique ways of traversing it, called full stochastic paths, which are used when determining how many different constraints need to be generated over time periods where stochastic_structures branch or converge, or when generating constraints involving different stochastic_structures. See the Stochastic Framework section for more information.

`report`

A results report from a particular SpineOpt run, including the value of specific variables.

Related Entity Classes: model__report and report__output

Related Parameters: output_db_url

A report is essentially a group of outputs from a model, that gets written into the output database as a result of running SpineOpt. Note that unless appropriate model__report and report__output relationships are defined, SpineOpt doesn't write any output!

`report__output`

An output that should be included in a report.

Related Entity Classes: output and report

Related Parameters: overwrite_results_on_rolling

The report__output relationship tells which output variables to include in which report when writing SpineOpt output. Note that the reports also need to be connected to a model using the model__report relationship. Without appropriately defined model__report and report__output and relationships, SpineOpt doesn't write any output, so be sure to include at least one report connected to all the output variables of interest in the model!

`settings`

Internal SpineOpt settings. We kindly advise not to mess with this one.

Related Parameters: version

Warning

Changing ANY SpineOpt internal settings manually is not recommended, unless you really know what you're doing!

`stage`

An additional stage in the optimisation problem (EXPERIMENTAL)

Related Entity Classes: stage__child_stage, stage__output__connection, stage__output__node, stage__output__unit and stage__output

Related Parameters: stage_scenario

Warning

EXPERIMENTAL!

See Decomposition.

`stage__child_stage`

A parent-child relationship between two stages (EXPERIMENTAL).

Related Entity Classes: stage

Warning

EXPERIMENTAL!

See Decomposition.

`stage__output`

An output that should be fixed by a stage for all entities in all its children (EXPERIMENTAL).

Related Entity Classes: output and stage

Related Parameters: output_resolution

Warning

EXPERIMENTAL!

See Decomposition.

`stageoutputconnection`

An output that should be fixed by a stage for a connection in all its children (EXPERIMENTAL).

Related Entity Classes: connection, output and stage

Related Parameters: output_resolution and slack_penalty

Warning

EXPERIMENTAL!

See Decomposition.

`stageoutputnode`

An output that should be fixed by a stage for a node in all its children (EXPERIMENTAL).

Related Entity Classes: node, output and stage

Related Parameters: output_resolution and slack_penalty

Warning

EXPERIMENTAL!

See Decomposition.

`stageoutputunit`

An output that should be fixed by a stage for a unit in all its children (EXPERIMENTAL).

Related Entity Classes: output, stage and unit

Related Parameters: output_resolution and slack_penalty

Warning

EXPERIMENTAL!

See Decomposition.

`stochastic_scenario`

A scenario for stochastic optimisation in SpineOpt.

Related Entity Classes: parent_stochastic_scenario__child_stochastic_scenario and stochastic_structure__stochastic_scenario

Essentially, a stochastic_scenario is a label for an alternative period of time, describing one possibility of what might come to pass. They are the basic building blocks of the scenario-based Stochastic Framework in SpineOpt.jl, but aren't really meaningful on their own. Only when combined into a stochastic_structure using the stochastic_structure__stochastic_scenario and parent_stochastic_scenario__child_stochastic_scenario relationships, along with Parameters like the weight_relative_to_parents and stochastic_scenario_end, they become meaningful.

`stochastic_structure`

A group of stochastic scenarios that represent a structure.

Related Entity Classes: connection__investment_stochastic_structure, model__default_investment_stochastic_structure, model__default_stochastic_structure, node__investment_stochastic_structure, node__stochastic_structure, stochastic_structure__stochastic_scenario, unit__investment_stochastic_structure and units_on__stochastic_structure

The stochastic_structure is the key component of the scenario-based Stochastic Framework in SpineOpt.jl, and essentially represents a group of stochastic_scenarios with set Parameters. The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structures, and the weight_relative_to_parents and stochastic_scenario_end Parameters define the exact shape and impact of the stochastic_structure, along with the parent_stochastic_scenario__child_stochastic_scenario relationship.

The main reason as to why stochastic_structures are so important is, that they act as handles connecting the Stochastic Framework to the modelled system. This is handled using the Structural relationship classes e.g. node__stochastic_structure, which define the stochastic_structure applied to each object describing the modelled system. Connecting each system object to the appropriate stochastic_structure individually can be a bit bothersome at times, so there are also a number of convenience Meta relationship classes like the model__default_stochastic_structure, which allow setting model-wide defaults to be used whenever specific definitions are missing.

`stochastic_structure__stochastic_scenario`

A stochastic_scenarios that belongs in a stochastic_structure.

Related Entity Classes: stochastic_scenario and stochastic_structure

Related Parameters: stochastic_scenario_end and weight_relative_to_parents

The stochastic_structure__stochastic_scenario relationship defines which stochastic_scenarios are included in which stochastic_structure, as well as holds the stochastic_scenario_end and weight_relative_to_parents Parameters defining how the stochastic_structure interacts with the Temporal Framework and the Objective function. Along with parent_stochastic_scenario__child_stochastic_scenario, this relationship is used to define the exact properties of each stochastic_structure, which are then applied to the objects describing the modelled system according to the Structural relationship classes, like the node__stochastic_structure relationship.

`temporal_block`

A length of time with a particular resolution.

Related Entity Classes: connection__investment_temporal_block, model__default_investment_temporal_block, model__default_temporal_block, node__investment_temporal_block, node__temporal_block, unit__investment_temporal_block and units_on__temporal_block

Related Parameters: block_end, block_start, has_free_start, representative_block_index, representative_blocks_by_period, resolution and weight

A temporal block defines the temporal properties of the optimization that is to be solved in the current window. It is the key building block of the Temporal Framework. Most importantly, it holds the necessary information about the resolution and horizon of the optimization. A single model can have multiple temporal blocks, which is one of the main sources of temporal flexibility in Spine: by linking different parts of the model to different temporal blocks, a single model can contain aspects that are solved with different temporal resolutions or time horizons.

`unit`

A conversion of one/many commodities between nodes.

Related Entity Classes: node__to_unit, stage__output__unit, unit__investment_group, unit__investment_stochastic_structure, unit__investment_temporal_block, unit__to_node, unit__user_constraint, units_on__stochastic_structure and units_on__temporal_block

Related Parameters: availability_factor, benders_starting_units_invested, curtailment_cost, decommissioning_time, discount_rate_technology_specific, existing_units, fom_cost, investment_count_fix_cumulative, investment_count_fix_new, investment_count_initial_cumulative, investment_count_initial_new, investment_count_max_cumulative, investment_variable_type, is_renewable, lead_time, lifetime_constraint_sense, lifetime_economic, lifetime_technical, mga_investment_active, mga_investment_big_m, mga_investment_weight, min_down_time, min_up_time, online_count_fix, online_count_initial, online_variable_type, out_of_service_count_fix, out_of_service_count_initial, outage_scheduled_duration, outage_variable_type, shut_down_cost, start_up_cost, unit_decommissioning_cost, unit_investment_cost, units_on_cost, units_on_non_anticipativity_margin and units_on_non_anticipativity_time

A unit represents an energy conversion process, where energy of one commodity can be converted into energy of another commodity. For example, a gas turbine, a power plant, or even a load, can be modelled using a unit.

A unit always takes energy from one or more nodes, and releases energy to one or more (possibly the same) nodes. The former are specified through the node__to_unit relationship, and the latter through unit__to_node. Every unit has a temporal and stochastic structures given by the units_on__temporal_block and [units_on__stochastic_structure] relationships. The model will generate unit_flow variables for every combination of unit, node, direction (from node or to node), time slice, and stochastic_scenario, according to the above relationships.

The operation of the unit is specified through a number of parameter values. For example, the capacity of the unit, as the maximum amount of energy that can enter or leave it, is given by capacity_per_unit. The conversion ratio of input to output can be specified using any of flow_ratio_equality_coefficient, flow_ratio_less_than_coefficient, and flow_ratio_greater_than_coefficient. The variable operating cost is given by vom_cost.

`unit__investment_group`

A unit that belongs in an investment_group.

Related Entity Classes: investment_group and unit

Assigns units to investment_groups, affecting the use of parameters like investment_capacity_total_max_cumulative or investment_capacity_total_min_cumulative.

`unit__investment_stochastic_structure`

The stochastic_structure of a unit investment.

Related Entity Classes: stochastic_structure and unit

The unit__investment_stochastic_structure relationship defines the stochastic_structure of unit-related investment decisions. Essentially, it sets the stochastic_structure used by the units_invested_available variable of the unit.

The unit__investment_stochastic_structure relationship uses the model__default_investment_stochastic_structure relationship if not defined.

`unit__investment_temporal_block`

The temporal_block of a unit investment.

Related Entity Classes: temporal_block and unit

unit__investment_temporal_block is a two-dimensional relationship between a unit and a temporal_block. This relationship defines the temporal resolution and scope of a unit's investment decision. If a model__default_investment_temporal_block is specified and no unit__investment_temporal_block relationship is specified, the model__default_investment_temporal_block relationship will be used. Conversely, if unit__investment_temporal_block is specified, this will override model__default_investment_temporal_block for the specified unit.

See also Investment Optimization

`unit__to_node`

A flow on a unit to a node.

Related Entity Classes: node and unit

Related Parameters: capacity_per_unit, capacity_to_flow_conversion_factor, fix_nonspin_units_shut_down, fix_nonspin_units_started_up, flow_limits_fix_op, flow_limits_fix, flow_limits_initial_op, flow_limits_initial, flow_limits_max_cumulative, flow_limits_min_cumulative, flow_limits_min, fuel_cost, initial_nonspin_units_shut_down, initial_nonspin_units_started_up, minimum_operating_point, operating_points, ordered_unit_flow_op, ramp_limits_down, ramp_limits_shutdown, ramp_limits_startup, ramp_limits_up, reserve_procurement_cost, unit_flow_non_anticipativity_margin, unit_flow_non_anticipativity_time and vom_cost

Various parameters can be defined on the unit__to_node relationship, in order to constrain the associated unit flows. In most cases a capacity_per_unit will be defined for an upper bound on the commodity flows. Apart from that, ramping abilities of a unit can be defined. For further details on ramps see Ramping.

To associate costs with a certain commodity flow, cost terms, such as fuel_costs and vom_costs, can be included for the unit__to_node relationship.

It is important to note, that the parameters associated with the unit__to_node can be defined either for a specific node, or for a group of nodes. Grouping nodes for the described parameters will result in an aggregation of the unit flows for the triggered constraint, e.g. the definition of the capacity_per_unit on a group of nodes will result in an upper bound on the sum of all individual unit_flows.

`unit__user_constraint`

A unit commitment constrained by a user_constraint.

Related Entity Classes: unit and user_constraint

Related Parameters: coefficient_for_units_invested_available, coefficient_for_units_invested, coefficient_for_units_on and coefficient_for_units_started_up

unit__user_constraint is a two-dimensional relationship between a unit and a user_constraint. The relationship specifies that a variable or variable(s) associated only with the unit (not a unit_flow for example) are involved in the constraint. For example, the coefficient_for_units_on defined on unit__user_constraint specifies the coefficient of the unit's units_on variable in the specified user_constraint.

`unit_flow`

A superclass for unit__to_node and node__to_unit classes.

Subclasses: node__to_unit, unit__to_node

Related Entity Classes: unit_flow__investment_group, unit_flow__unit_flow and unit_flow__user_constraint

Effectively provides a single handle for all unit_flow variables, regardless of whether they belong to node__to_unit or unit__to_node.

`unit_flow__investment_group`

A flow on a unit from/to a node whose capacity should be counted in the capacity invested available of an investment_group.

Related Entity Classes: investment_group and unit_flow

Relates an unit_flow and its respective unit_flow variable to an investment_group. Used for e.g. the investment_capacity_total_max_cumulative.

`unit_flow__unit_flow`

Two unit_flow entities (and variables) that are constrained by each other.

Related Entity Classes: unit_flow

Related Parameters: flow_ratio_equality_coefficient, flow_ratio_equality_online_coefficient, flow_ratio_greater_than_coefficient, flow_ratio_greater_than_online_coefficient, flow_ratio_less_than_coefficient, flow_ratio_less_than_online_coefficient and flow_ratio_start_flow

Effectively used to relate two unit_flow entities together to bind their respective unit_flow variables. Typically used for parameters like flow_ratio_equality_coefficient, e.g. in How to define an efficiency.

`unit_flow__user_constraint`

A flow on a unit from/to a node constrained by a user_constraint.

Related Entity Classes: unit_flow and user_constraint

Related Parameters: coefficient_for_unit_flow

unit_flow__user_constraint is a relationship between a unit_flow and a user_constraint. The relationship specifies that the unit_flow variable between the specified unit and the specified node is involved in the specified user_constraint. Parameters on this relationship generally apply to this specific unit_flow variable. For example the parameter coefficient_for_unit_flow defined on unit_flow__user_constraint represents the coefficient on the specific unit_flow variable in the specified user_constraint

`units_on__stochastic_structure`

The stochastic_structure of a unit commitment. Only one stochastic_structure is permitted per unit.

Related Entity Classes: stochastic_structure and unit

The units_on__stochastic_structure relationship defines the stochastic_structure used by the units_on variable. Essentially, this relationship permits defining a different stochastic_structure for the online decisions regarding the units_on variable, than what is used for the production unit_flow variables. A common use-case is e.g. using only one units_on variable across multiple stochastic_scenarios for the unit_flow variables. Note that only one units_on__stochastic_structure relationship can be defined per unit per model, as interpreted by the units_on__stochastic_structure relationship.

The units_on__stochastic_structure relationship uses the model__default_stochastic_structure relationship if not specified.

`units_on__temporal_block`

The temporal_block of a unit commitment.

Related Entity Classes: temporal_block and unit

units_on__temporal_block is a relationship linking the units_on variable of a unit to a specific temporal_block object. As such, this relationship will determine which temporal block governs the on- and offline status of the unit. The temporal block holds information on the temporal scope and resolution for which the variable should be optimized.

`user_constraint`

A generic data-driven custom constraint.

Related Entity Classes: connection__from_node__user_constraint, connection__to_node__user_constraint, connection__user_constraint, node__user_constraint, unit__user_constraint and unit_flow__user_constraint

Related Parameters: constraint_sense, right_hand_side and user_constraint_slack_penalty

The user_constraint is a generic data-driven custom constraint, which allows for defining constraints involving multiple units, nodes, or connections. The constraint_sense parameter changes the sense of the user_constraint, while the right_hand_side parameter allows for defining the constant terms of the constraint.

Coefficients for the different variables appearing in the user_constraint are defined using relationships, like e.g. unit_flow__user_constraint and connection__to_node__user_constraint for unit_flow and connection_flow variables, or unit__user_constraint and node__user_constraint for units_on, units_started_up, and node_state variables.

For more information, see the dedicated article on User Constraints